On Abstraction in Finite State Machine Models

Information hiding is a long established principle in software engineering. However, in the context of finite state machines a contrary principle of information exposure has been suggested. Using a simple example, we examine why a proven abstraction mechanism which works well in other areas may be less successful when applied to a finite state machine model. After using Statecharts [3] to specify an aeronautical application, Leveson et al. [5, 6] report a difficulty that arose with hierarchical abstraction: Transitions involving superstates became difficult to understand when the substates they ultimately connected were shown separately on lower level diagrams. From this, they conclude that information hiding [7] impaired the specification’s understandability. For requirements specifications, they recommend instead maximizing “information exposure.” The problem that we perceive and describe here relates neither generally to requirements specification nor specifically to Statecharts. It is a problem with abstraction peculiar to finite state machine (FSM) models. To illustrate, we examine hierarchical abstraction as used in Structured Analysis, [2], with its equivalent in Real-Time Structured Analysis / Structured Design (RTSASD) [8, 4]. Figure 1 shows the general form of a data flow diagram (DFD) as used in Structured Analysis. A data transform in a DFD is labelled with an action describing what it does. For example, a transform called “Configure Alarms” might accept input data flows which indicate whether various faults are present and the severities assigned to these faults and produce an output flow indicating which alarms should be active. The “how” of a transform is then described at a lower level, perhaps using another DFD with more transforms. Regardless of the efficacy or otherwise of the top-down approach itself, a data transform is generally suited to this kind of abstraction since it can be understood in terms of its function and its inputs and outputs. The relationship between data transforms and data flows is one of function and necessity: the function of the transform is to produce the output flows; to do this it needs the input flows. As analogues to data transforms, control transforms in RTSASD accept control flow inputs and may be seen as transforming these into control flow outputs. Control flows carry instantaneous events and control transforms are ultimately specified